- Архитектура
- Код
- Процессы работы со сбоями
- Подготовка к устранению сбоев
- Базовые принципы и ценности инженера по надежности
Надежную работу можно ожидать только, если все аспекты информационной системы сделаны надлежащим образом.
Когда мы говорим "все аспекты", то мы включаем не только архитектуру, код, тестирование, но работу людей, которые обслуживают систему, отработанность действий во время сбоев, понятность и удобство служебных интерфейсов, обученность и так далее.
Современные системы очень сложны. Они часто представляют из себя не только сложный код, но и как правило множество сложно взаимодействующих друг с другом микросервисов. Хитросплетение самописного нового и старого кода, купленных продуктов, программно-аппаратных комплексов, облачных сервисов — то, с чем мы чаще всего имеем дело в настоящее время.
Нас интересует повышение надежности реальных систем. Поэтому мы не будем рассуждать о том, как "правильно" с нуля создать идеальную систему, но скорее о том, в каком направлении работать с накопленным инженерным наследием, которое имеет типичная компании переросшая стадию стартапа, когда надежность преобретает особую ценность и значимость.
Высокая надежность — это очень дорого и не всегда оправданно. Я встречал инженеров, которые качество кода ценят превыше всего и готовы повышать его до максимально доступного практически уровня не считаясь со стоимостью и целесообразностью. Вместо этого я призываю искать баланс между сложностью, стоимостью и оправданностью. Не стоит пытаться применить каждый совет отсюда в каждой системе. Это почти всегда будет избыточно. Я считаю, что работа инженера — зная и умея применять все описанные здесь приемы и практики, выбирать и реализовывать то, что наиболее целесообразно и подходит ситуации.
Мы будем рассматривать создание надежной системы в следующем порядке. Начнем с аспектов архитектуры, которые сильно вляют на недежность или используются для увеличения надежности. Затем рассмотрим важные приемы при написании кода. Затем поговорим о процессах вокруг наших систем (мониторинг, алертирование и т.п.). Далее будет информация о организации работы команд, обучении, подготовки к сбоям.
Поскольку конкрентные финальные решения и приемы — дело творчества конкретной инженерной команды, то сначала хочется рассмотреть самые базовые принципы и ценности, которые в самом общем виде помогут принимать ежедневные решения при работе над современными информационными системами. Некое "ДНК" инженера по надежности.
Базовые ценности для обеспечения бесперебойной работы
Надежда — это не стратегия.
Мы не должны рассчитывать на удачу и что "пронесет". Закон Мерфи гласит: "Если неприятность может случиться, она случится". Железо отказывает, люди ошибаются, а пользователи вдруг разом и невовремя начинают массово пользоваться нашими услугами, которые вчера существовали без нагрузки. Мы должны рассчитывать, быть готовы и иметь стратегию действия в различных ситуациях, которая будет лучше, чем "надеемся, что этого не случится".
Проблемы в продакшен имеют наивысший приоритет.
Руководство, просто коллеги ждущие тебя на встрече или еще чего-то — все подождет, пока ты занимаешься сбоем в продакшен. Получив нотификацию о сбое, следует прекратить любую другую активность и заняться спасением сервиса. Из этого следует несколько простой вывод: не планируй ничего важного (собеседование, презентации), если ты в это время дежурный за важную систему. Ищи подмену.
Простой, но работающий сервис лучше, чем крутой, но не работающий.
Это простое соображение расставляет для нас приоритеты, когда казалось бы и так сойдет и можно наделать много новых фич.
Когда в продакшен все хорошо, SRE готовится к возможным сбоям.
Когда все хорошо нам надо писать тулы, полезные инструменты и улучшать наши системы. На это должно уходить минимум 40-60% рабочего времени. Если тратишь по ощущениям меньше 40% — значит система в критическом состоянии и требует слишком много ручного внимания.
Система, которая давно не модифицировалась, взрывается громче, чем та, которую регулярно обновляют.
Мы не считаем, что лучше "не трогать то, что работает". Напротив, экспертиза постепенно вымывается и неподдерживаемый софт грозит нам более сложными сбоями. "Работает — не трогай" — устаревший и очень вредный совет.
Каждый сбой следует использовать для обучения.
Не расстраиваемся, если мы ошиблись. Это материал для обучения. Необходимо постоянно изучать свои системы и их поведение. Поскольку современные системы очень сложны знать полностью их уже невозможно. Полностью их поведение как правило давно уже не знает и их создатели. Но его можно и нужно изучать и сбои — очень интересный период в жизни системы, который дает много информации о ней.
Люди ошибаются.
Поэтому нам нужны системы, которые защищают от человеческих ошибок. Не надо ругать человека за ошибку, надо понять, почему в данной ситуации возможно было ошибиться.